As AI generates code faster than humans can write it, good taste in programming moves upstream—from judging individual lines to asking the right questions about what to build. The programmers who'll get most out of AI tools are those who already know what they want.

• Human taste during coding happens at typing speed, which constrains damage from bad decisions. AI removes that slowness, so taste becomes a reviewing filter—but reviewing is harder than writing and happens too late to catch fundamental design mistakes.
• The most important choices (what to build, how to split it, what to omit) happen before the model writes anything. A well-executed answer to the wrong question is still wrong.
• Models will get good at local code judgment (idioms, naming, structure) but can't learn domain-specific taste—knowing which complexity matters, how users will behave, where the system will change. That knowledge lives with the people who own the problem.

Mark Seemann argues that fully LLM-driven software engineering could work—producing code as reliable as human-written systems—but legal systems will struggle to assign blame when things go wrong, likely scapegoating whoever signed off on the release rather than the AI that created the defect.

• Code review and human inspection were never foolproof either; the real question isn't whether LLM code is perfect, but whether it's better than human-driven processes, which it plausibly could be.
• Even if LLM-driven systems produce fewer bugs than human teams, courts and liability frameworks aren't equipped to handle a world where no individual "wrote" the problematic code—judges will still need someone to prosecute.
• People will adopt AI-driven systems aggressively (like Tesla FSD drivers ignoring the road) because the odds look good, then face severe legal consequences when rare failures occur, regardless of how robust their quality assurance actually was.

Sean Goedecke argues that software engineers have no moral standing to resist AI automation, since the entire profession has always been about automating other people's jobs. He compares engineers opposing AI to the mechanics who built power looms and then complained when their own skills became obsolete.

• Software engineering's core purpose is automating human labor—from spreadsheets displacing bookkeepers to software eliminating video rental stores, travel agencies, and data entry jobs. Engineers can't claim this is suddenly wrong now that it's happening to them.
• The historical parallel to Luddites doesn't work: software engineers are like the mechanics who built the automation machines, not the workers being displaced. Those same mechanics were automated away 50 years later and were seen as hypocrites for resisting it.
• If engineers genuinely believe technological progress is harmful, they should quit. Complaining about AI while continuing to build automation is intellectually dishonest—it's "pulling the ladder up behind you" only after you've climbed it.

A staff engineer argues that AI coding tools are improving fast enough to make most software engineering jobs obsolete within a decade, and that past predictions of industry doom don't apply because those technologies never actually replaced programmers while AI likely will.

• AI agents are already better than many engineers at code maintenance and debugging, not just writing new code, which undermines the argument that humans will always be needed to clean up AI-generated code.
• Junior and mid-level engineers will face job losses first; senior staff engineers supervising AI agents may survive longer, but this represents a massive contraction in total engineering headcount, not job security.
• The Jevons effect (increased demand offsetting productivity gains) probably won't save the industry because AI can handle both code creation and maintenance equally well, unlike past automation waves that only eliminated specific tasks.

Jake Goldsborough argues that AI coding agents aren't killing software engineering—they're freeing engineers from tedious mechanical work so they can focus on the actual problem-solving that defines the craft. The hard parts that never mattered (regex wrestling, syntax memorization, build system incantations) are disappearing, but the work that requires real judgment and responsibility remains.

• The difficult parts of coding—parsing edge cases, remembering obscure syntax, navigating unfamiliar codebases—were never the point; they were tolls between understanding a problem and solving it, and removing them doesn't diminish engineering skill.
• Agents handle syntax and scaffolding faster, which lets engineers explore domains that were previously too expensive (rewriting programs in different languages, understanding unfamiliar systems, testing experimental ideas), actually tightening the learning loop rather than replacing it.
• The real shift is architectural: engineering moves from "produce every character by hand" to "direction, judgment, verification, and responsibility," and the actual risk isn't that the work disappears but that companies cut people, generated code creates failures at scale, and the junior-to-senior training path collapses.

Studies show that medical specialists’ ability to detect lesions in endoscopy drops significantly when AI assistance is removed, and similar trials are underway in software engineering. Experts warn that over-reliance on AI can impair hard-won skills and call for research into ways to preserve human expertise.

• Polish endoscopy specialists' adenoma-detection rate dropped from 28.4% to 22.4% when AI assistance was switched off after they'd grown used to it.
• 70% of US nurses and 77% of physicians already worry AI reliance is eroding their clinical skills.
• Anthropic's trial with 52 software engineers found those who habitually used AI took longer and made more errors solving problems without it.
• Researchers like Yuichi Mori say there's no clear fix yet and want "deskilling" made a top research priority.

The article explores the definition of an engineer and what engineering truly entails, especially in the context of advancing AI technology. It emphasizes that engineering is about taking the right actions in the right sequence to achieve various intentions, highlighting the importance of clarity in project goals and the art of sequencing tasks.

• An engineer is defined as someone who takes the right actions in the right sequence to achieve a set of intentions, not someone who builds physical things—making software engineers legitimately engineers.
• Engineering projects have multiple simultaneous intentions (resources, stakeholders, users), and failing to articulate them causes teams to build the wrong product or misalign with goals.
• Sequencing matters as much as choosing the right actions—order of operations determines success, and sequences nest recursively within larger sequences (illustrated via the hand-washing example).